March 17, 201610 yr I had a random issue where I was unable to write to a share using the Windows Explorer interface. I rebooted and the problem went away. However, for some reason, within a certain docker I use, I'm being told "unable to create file ....." directory is not writable? How do I make sure that a directory is writable, specifically, by any user on the network?
March 17, 201610 yr Community Expert I had a random issue where I was unable to write to a share using the Windows Explorer interface. I rebooted and the problem went away. However, for some reason, within a certain docker I use, I'm being told "unable to create file ....." directory is not writable? How do I make sure that a directory is writable, specifically, by any user on the network? Make sure that the owner is nobody and, under no circumstances, the owner can not be root .
March 17, 201610 yr Author I had a random issue where I was unable to write to a share using the Windows Explorer interface. I rebooted and the problem went away. However, for some reason, within a certain docker I use, I'm being told "unable to create file ....." directory is not writable? How do I make sure that a directory is writable, specifically, by any user on the network? Make sure that the owner is nobody and, under no circumstances, the owner can not be root . The only setting I see is when selecting the share, I can set SMB Security Settings to "public". Under the share settings, there are basic details like disks included, share name, comments, etc., but nothing about ownership.
March 17, 201610 yr Community Expert ... within a certain docker I use, I'm being told "unable to create file ....." directory is not writable?... Sounds like you have an issue with a certain docker. Did you ask at that docker's support thread? Maybe if you actually told us the identity of that certain docker someone might have some more specific advice.
March 17, 201610 yr Author ... within a certain docker I use, I'm being told "unable to create file ....." directory is not writable?... Sounds like you have an issue with a certain docker. Did you ask at that docker's support thread? Maybe if you actually told us the identity of that certain docker someone might have some more specific advice. It's mythTV when setting the storage directory.
March 17, 201610 yr Author So I have a quick workaround to the problem. The issue is certainly the inability for some reason to write to disk 1. I read someone having a similar issue on the mythtv docker thread. Someone said: "I think that this error also occurs if you are not able to write to your timeshift location (called LiveTV in the storage directories)." I noticed I was having the issue writing, so I decided to forward any writing to a drive where I knew I was able to write. I created a port mapping directly to disk 2. TV is now streaming fine. Still, if I go to windows explorer, I can't create a folder in disk 1. I can't for the life of me figure out what the issue is. The only difference I see is that the file system type for disk 1 is reiserfs and disk 2 is xfs. I did some quick googling on changing drive permissions, but I'm having issues. It doesn't seem like there is anything simple on the unRAID GUI. Thoughts?
March 17, 201610 yr The file system might be mounted as read-only...post diagnostics. Tools>Diagnostics
March 17, 201610 yr Author The file system might be mounted as read-only...post diagnostics. Tools>Diagnostics It's odd, because immediately at bootup, I can create a folder. Check back 30 seconds later and I don't have permissions. I have added the diagnostic file. tower-diagnostics-20160317-1819.zip
March 17, 201610 yr Community Expert The syslog included in the diagnostics files shows that you HAVE got file system corruption on disk 1, and it is therefore being remounted as read-only. This can be fixed by running reiserfsck against the disk with the array in maintenance mode. With the current release (6.1.9) this is available via the GUI by clicking on the drive while running in Maintenance mode. However the syslog shows that you still appear to be on 6.1.3 so I am not sure if at that stage you could do such a check from the GUI or whether it needs to be done from the command line.
March 18, 201610 yr Author The syslog included in the diagnostics files shows that you HAVE got file system corruption on disk 1, and it is therefore being remounted as read-only. This can be fixed by running reiserfsck against the disk with the array in maintenance mode. With the current release (6.1.9) this is available via the GUI by clicking on the drive while running in Maintenance mode. However the syslog shows that you still appear to be on 6.1.3 so I am not sure if at that stage you could do such a check from the GUI or whether it needs to be done from the command line. Thanks for the diagnosis! I will assess and report back.
March 18, 201610 yr Author I'm running the check, but it seems to be stuck at "Replaying journal: Done. Reiserfs journal '/dev/md1' in blocks [18..8211]: 7 transactions replayed Checking internal tree.." Been here for 10 minutes now with no progress. Out of curiosity, what lines did you see on the log file that clued you in to this being the issue?
March 18, 201610 yr Community Expert Out of curiosity, what lines did you see on the log file that clued you in to this being the issue? Mar 17 18:19:02 Tower kernel: REISERFS error (device md1): vs-7000 search_by_entry_key: search_by_key returned item position == 0 Mar 17 18:19:02 Tower kernel: REISERFS (device md1): Remounting filesystem read-only Mar 17 18:19:03 Tower shfs/user: shfs_readdir: fstatat: Shark.Tank.S01E08.720p.HDTV.x264-NTB.nzb.2.queued (5) Input/output error Mar 17 18:19:03 Tower shfs/user: shfs_readdir: readdir_r: /mnt/disk1/NZBGet/nzb files (5) Input/output error Mar 17 18:19:03 Tower kernel: REISERFS error (device md1): vs-7000 search_by_entry_key: search_by_key returned item position == 0 Mar 17 18:19:03 Tower kernel: REISERFS error (device md1): zam-7001 reiserfs_find_entry: io error Also, there was a bug running resiserfsck from the WebGUI that was only fixed on 6.1.7, since you're on 6.1.3 you should run it from the command line.
March 18, 201610 yr You're fortunate enough to be running RFS file systems still, if this were BTRFS it would be a completely different story. While development of RFS has stopped (on account of the creator being jailed for murder) it is still robust and the tools that are available for it are nothing short of miracle workers.
March 18, 201610 yr Author Out of curiosity, what lines did you see on the log file that clued you in to this being the issue? Mar 17 18:19:02 Tower kernel: REISERFS error (device md1): vs-7000 search_by_entry_key: search_by_key returned item position == 0 Mar 17 18:19:02 Tower kernel: REISERFS (device md1): Remounting filesystem read-only Mar 17 18:19:03 Tower shfs/user: shfs_readdir: fstatat: Shark.Tank.S01E08.720p.HDTV.x264-NTB.nzb.2.queued (5) Input/output error Mar 17 18:19:03 Tower shfs/user: shfs_readdir: readdir_r: /mnt/disk1/NZBGet/nzb files (5) Input/output error Mar 17 18:19:03 Tower kernel: REISERFS error (device md1): vs-7000 search_by_entry_key: search_by_key returned item position == 0 Mar 17 18:19:03 Tower kernel: REISERFS error (device md1): zam-7001 reiserfs_find_entry: io error Also, there was a bug running resiserfsck from the WebGUI that was only fixed on 6.1.7, since you're on 6.1.3 you should run it from the command line. Here's what it says. Not sure what it means. reiserfsck finished at Fri Mar 18 14:30:43 2016 ########### bad_stat_data: The objectid (92553) is shared by at least two files. Can be fixed with --rebuild-tree only. bad_stat_data: The objectid (92559) is shared by at least two files. Can be fixed with --rebuild-tree only. bad_stat_data: The objectid (92587) is shared by at least two files. Can be fixed with --rebuild-tree only. bad_path: The left delimiting key [2080 92587 0xe1 DRCT (2)] of the node (336073077) must be equal to the first element's key [2080 92549 0x1e1 DRCT (2)] within the node. bad_path: block 503730774, pointer 6: The used space (3592) of the child block (503382304) is not equal to the (blocksize (4096) - free space (3880) - header size (24)) bad_path: block 503730774, pointer 9: The used space (3228) of the child block (503382328) is not equal to the (blocksize (4096) - free space (772) - header size (24)) bad_path: block 503730774, pointer 12: The used space (3496) of the child block (503382329) is not equal to the (blocksize (4096) - free space (24) - header size (24)) bad_path: The left delimiting key [3007 12705 0x5e2bb380 DIR (3)] of the node (503382324) must be equal to the first element's key [3007 12705 0x614d5980 DIR (3)] within the node. bad_stat_data: The objectid (92404) is shared by at least two files. Can be fixed with --rebuild-tree only. bad_stat_data: The objectid (92432) is shared by at least two files. Can be fixed with --rebuild-tree only. bad_path: block 503730774, pointer 32: The used space (3768) of the child block (503382312) is not equal to the (blocksize (4096) - free space (36) - header size (24)) bad_stat_data: The objectid (92433) is shared by at least two files. Can be fixed with --rebuild-tree only. bad_stat_data: The objectid (92434) is shared by at least two files. Can be fixed with --rebuild-tree only. bad_stat_data: The objectid (92435) is shared by at least two files. Can be fixed with --rebuild-tree only. bad_stat_data: The objectid (92436) is shared by at least two files. Can be fixed with --rebuild-tree only. bad_stat_data: The objectid (92437) is shared by at least two files. Can be fixed with --rebuild-tree only. bad_path: The left delimiting key [3007 92519 0x0 SD (0)] of the node (503593364) must be equal to the first element's key [3007 92432 0x1 DRCT (2)] within the node. vpf-10640: The on-disk and the correct bitmaps differs.
March 18, 201610 yr Community Expert Means you have to run reiserfsck with the --rebuild-tree option.
March 18, 201610 yr Just know, the rebuild-tree option will take a long time to run. It essentially rebuilds the journal entries based on the raw data on the drive.
March 19, 201610 yr Author Means you have to run reiserfsck with the --rebuild-tree option. If I switch the file system of this drive to XFS, will I still have this problem when rewriting the content?
March 19, 201610 yr Community Expert Means you have to run reiserfsck with the --rebuild-tree option. If I switch the file system of this drive to XFS, will I still have this problem when rewriting the content? Suggest you first read this. Converting a disk from reiserfs to XFS is not a simple matter. Particularly as you have errors on that disk. It may well be that those errors are also incorporated into the parity information. (BTW, the reiserfs repair tools are VERY good and most people have had good results using them. johnnie.black is well qualified to lead you through the process.) http://lime-technology.com/forum/index.php?topic=37490.0
March 19, 201610 yr Author Just know, the rebuild-tree option will take a long time to run. It essentially rebuilds the journal entries based on the raw data on the drive. When I tried the rebuild-tree option it said it couldn't find the superblock! Might have bigger problems than I expected... If I read the above sticky correctly, I can't just switch the file system since it's a bit for bit copy and not file for file. But if I copy the contents of the drive to another drive, wipe the drive clean and change the file system to XFS, and then copy the files back over, I should be okay?
March 19, 201610 yr Community Expert Just know, the rebuild-tree option will take a long time to run. It essentially rebuilds the journal entries based on the raw data on the drive. When I tried the rebuild-tree option it said it couldn't find the superblock! Might have bigger problems than I expected... What was the exact command that was run? Often this error indicates the device name was not correct.
March 19, 201610 yr Community Expert Rebuilding the superblock is often needed when doing –rebuild-tree, see here how to answer the questions. If you have the space, it can however be a better idea to copy all the data to another disk and format to xfs. All commands should be run for /dev/md1 (disk1)
March 19, 201610 yr Community Expert Rebuilding the superblock is often needed when doing –rebuild-tree, see here how to answer the questions. I would say 'often' is definitely not the case. I have seen more occurrences of that message where the raw device name has been used (omitting partition number) than genuine cases that need it. Which is one reason for always asking for more detail before the user goes ahead and messes things up in a case where they used the wrong command. Having said that if the array is properly put into Maintenance mode and the /dev/mdX devices used then the chance of errors goes way down.
March 19, 201610 yr Author Rebuilding the superblock is often needed when doing –rebuild-tree, see here how to answer the questions. I would say 'often' is definitely not the case. I have seen more occurrences of that message where the raw device name has been used (omitting partition number) than genuine cases that need it. Which is one reason for always asking for more detail before the user goes ahead and messes things up in a case where they used the wrong command. Having said that if the array is properly put into Maintenance mode and the /dev/mdX devices used then the chance of errors goes way down. Got this message: Bad root block 0. (--rebuild-tree did not complete) So is there any way to copy some of the files off of this drive, format it to XFS and then repopulate data without actually adding a new drive to the array and using the parity feature? I also have not tried to rebuild the superblock.
March 19, 201610 yr Community Expert You can copy over lan to another computer or search for the unassigned devices plugin.
Archived
This topic is now archived and is closed to further replies.