dlandon
-
Posts
10,398 -
Joined
-
Last visited
-
Days Won
20
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Everything posted by dlandon
-
Go to the Recycle Bin and click on the trash can and browse the trash. Click on the User Shares. All you should see are the shares with .Recycle.Bin contents. If you see any reference to /mnt/user/ let me know.
-
I have no idea how you ended up with the /mnt/user/SHARENAME reference to delete the share trash, but I am now going to confirm that there is in fact a .Recycle.Bin folder on the share before adding it to the recycle bin browse. This might help prevent this in the future.
-
The log entry should look like this: Feb 4 11:01:32 BackupServer ool www[23953]: /usr/local/emhttp/plugins/recycle.bin/scripts/rc.recycle.bin 'share' '/mnt/RecycleBin/User Shares/SHARENAME/' There is no reference at all in the recycle bin shares to /mnt/user/. I changed all references in the recycle bin to a set of links directly to the recycle bins that I create at /mnt/RecycleBin. This is what you browse in the recycle bin UI. Once you get the SHARENAME working again, delete a file, then go to the 'Shares' tab and click on the Browse icon. Look at the URL when you are browsing and it should look like this: https://backupserver/Settings/RecycleBin/Browse?dir=/mnt/RecycleBin/User%20Shares/SHARENMAME This is the path to the .Recycle.Bin folder on SHARENAME. It should not show /mnt/user/SHARENAME. Let me know if it does.
-
This is a share empty trash. I'm trying to reproduce your issue here, but can't find it yet. Post your diagnostics so I can review the log.
-
So you deleted the share recycle bin from the 'Shares' tab? What was the name of the share?
-
I created a share called "Dan's Stuff". Unraid created a second share called "Dan_s Stuff" automatically. I'm working with the Recycle Bin plugin and when I delete a file on Dan's Stuff it shows in Dan_s Stuff. Two shares are actually created: [Dan's Stuff] path = /mnt/user/Dan's Stuff comment = Test share browseable = yes public = yes writeable = yes vfs objects = extd_audit recycle recycle:repository = %P/.Recycle.Bin/ recycle:directory_mode = 0777 recycle:keeptree = Yes recycle:touch = Yes recycle:touch_mtime = No recycle:minsize = 1 recycle:versions = Yes recycle:exclude = *.tmp,*.ign,*.db-* recycle:exclude_dir = .Recycle.Bin [Dan_s Stuff] path = /mnt/user/Dan_s Stuff comment = browseable = yes public = yes writeable = yes vfs objects = extd_audit recycle recycle:repository = %P/.Recycle.Bin/ recycle:directory_mode = 0777 recycle:keeptree = Yes recycle:touch = Yes recycle:touch_mtime = No recycle:minsize = 1 recycle:versions = Yes recycle:exclude = *.tmp,*.ign,*.db-* recycle:exclude_dir = .Recycle.Bin I didn't mark this as urgent because I don't think it results in data loss, but data might not show up as expected. I think this will also create a permissions issue because the 'ghost' share's default permissions are not set by the user. backupserver-diagnostics-20190204-0816.zip -
Don't use quotes. Should be appdata,system,flash not 'appdata','system','flash'.
-
I did make a change to the template some time ago that was the cause of some of this. Since you aren't helping me with any information about what is happening for you, all I can suggest is for you to delete the existing template and then get the default from CA and use it. Don't make any changes until you have it working. If that doesn't work, then delete the appdata/Zoneminder folder and the docker image and start over. I cannot duplicate this problem. I'll do what I can to help you, but I don't appreciate the condescending attitude. Like I am supposed to know what is wrong and why can't I just fix it! I can't figure out what is happening for you without information. There can be many things, including your network and your ability to configure it properly, that can be the problem. I'm not surprised about this I just need information to be able to figure it out.
-
No longer true. I'm releasing a new version that will not show any remote mounted shares and the local recycle bin will not remove any files from the remote share recycle bins. Only the local server will be able to manage the shares originating on that server. Changes: - The 'Shares' tab has been re-organized and you can click the table headers and sort the entries - for example the trash can sizes and share names. - You can stop the recycle bin and still manage files in the .Recycle.Bin folders. - Added additional help text. - Only local mounted shares will be included in the recycle bin size calculations and file browsing. - Empty and purge now only work with the shares that have the recycle bin enabled. All other shares with .Recycle.Bin folders are left alone.
-
Yes. UD device shares either locally mounted or remote mounted will not show. No. Excluding a share only excludes it on the local server. Remote mounted shares are cannot be excluded because they are mounted on another server. When shares are enabled on the recycle bin, the share is defined with the vfs_recycle that moves files to the .Recycle.Bin folder when they are deleted from the share. This puts files in the recycle bin. When a share is excluded from the recycle bin, no files are moved to the recycle bin when deleted. The contents of the .Recycle.Bin folder on the share will still show in the recycle bin if there are files in that folder, even though no further files will be moved there. To summarize: - When the recycle bin is enabled on a share, it has to be a local device share and files will be moved to the .Recycle.Bin folder when deleted from the share. - The recycle bin size and browsing shows devices with files in the share .Recycle.Bin folder, whether or not the recycle bin is enabled for that share. - Remote mounted devices will show in the recycle bin size and browsing when their .Recycle.Bin folder has content. The only way to turn this off is to not enable UD devices in the recycle bin. - Only local device shares can be excluded from the recycle bin.
-
Fixed in the latest release.
-
Try again.
-
I did find where the recycle bin was mis-handling UD devices when they were not enabled in the recycle bin. For example if the "Enable on Unassigned Devices?" is set to 'No' and the shares have files in the .Recycle.Bin folder and the recycle bin was emptied, those files would be deleted. When the "Enable on Unassigned Devices?" is set to 'No', the recycle bin will be disabled for that share and any files on those shares in the .Recycle.Bin folder will be left alone. This applies to all UD devices and remote mounts. This might be closer to what you are expecting of how the recycle bin should operate.
-
That's the way it currently works. Only physical devices are mounted at /mnt/disks/ and "Enable on Unassigned Devices?" enables/disables the recycle bin on the devices mounted at /mnt/disks/. Remote shares are only configured for either SMB or NFS sharing and not locally mounted. The share included or excluded from the recycle bin only applies to the original mount point because that is where the deleting of files is controlled. It has nothing to do with remote mounted shares on a different server seeing the .Recycle.Bin files. I'm not sure I see the point in all this. What difference does it make if the share .Recycle.Bin files are shown in the remote recycle bin or not?
-
You mentioned earlier that disabling the recycle bin didn't work as if you wanted it off. That's correct. The recycle bin is the total of all .Recyle.Bin folders on all shares. When a recycle bin is enabled, it applies to deleting files at the original source mount (Freda) . It has nothing to do with seeing the files already in the .Recycle.Bin folders. Any other server that remote mounts the share will also see the files in the .Recycle.Bin folder. Look at the 'Shares' tab of the recycle bin and you'll see the totals in the recycle bins of the individual shares.
-
I'm sorry, but this whole scheme is extremely confusing and screen shots with totals on the recycle bin tell me nothing about where the recycle bin files are located. Let me share some things that may be helpful. Let's look at your 4K share. The original source of the 4K share (where it is mounted - Freya) will be the source of the recycle bin. That share should be excluded from the recycle bin. Right now it is not based on your screen shots. Add 4K as an excluded share. If it is a UD device it will be excluded by setting 'Enable on Unassigned Devices?' set to 'No'. Now mount the share remotely through UD on Thor and Freya_Media. The recycle bin on that share on Thor and Freya_Media will not apply on those two servers. The 'Enable on Unassigned Devices?' set to 'Yes' does not apply to remote shares, only UD devices like disk drives. i.e. the source mount of the share. The best way to see the share recycle bin shares in on the shares tab. You can see where the files are located.
-
Post your diagnostics.
-
If you are sharing UD shares among the servers, the Recycle Bin on those shares will also show up on the other servers. Can you show screen shots of the Recycle Bin settings and the 'Shares' tab on one of the servers?
-
Unraid doesn't see any disks but the two in your array - sdb and sdc. If there are supposed to be others, you need to check your bios and see that they are recognized by the motherboard.
-
Ok. Sounds good to me.
-
It happens on my main server and my test server. I've turned on logging and will capture a log tonight.
-
I am getting a mover exit error every night when the mover runs: Jan 28 03:40:33 MediaServer crond[1723]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null What information do you need? Should I turn on mover logging?
-
Do you need any information? I can offer diagnostics if that would help. Is it even important?
-
Got some warning messages in the log: ** (filezilla:907): WARNING **: 06:00:05.327: invalid source position for vertical gradient It occurs multiple times. Is there any issue here?
-
Remove the UD plugin and see if the drives show up then as unassigned. If they do, let me know the drive designations.
